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I had been in a technical/project management assignment about two years, when one day 
my boss asked me to come to his office to “discuss an opportunity.” When i arrived in his 
office, he indicated that the project manager of one of our biggest ($10M+) and most 
important projects had requested to be removed from the job immediately, and the organ- 
ization was going to grant the request. He felt I was the most experienced person he had 
and thought I would be a perfect fit for this job. 


This job would, no doubt, pose challenges. 
Engineering was near completion and most of the 
equipment was on site — but only 20% of construction 
had been completed. I would have just six weeks to 
complete construction, start up the facility, and begin 
production. I was flattered to be considered, but realisti- 
cally knew I had only done one similar, but smaller, 
project in my career. 

I had managed that project from the start to the 
end — so I had no experience with assuming another 
manager’s project. This assignment would be a three- 
to six-month job at a remote location. I would need to 


be on site in just two days, in order to have transition 
time with the old project manager. I worried this 
wouldn't be enough time to learn everything that I 
would need to know. 

After thinking it over for a night, I accepted the 
assignment, packed my bags, and arrived on site ready 
to debrief with the project manager — only to discover 
the project manager had decided not to return to the 
site. Thus, my transition time was zero. I focused, 
instead, on meeting the rest of the team and learned 
another key piece of the puzzle: There were serious 
interpersonal and functional issues within the team. 
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Team members were candid with me — many told 
me that they didn’t like other people on the team, or 
they wanted to be working outside their current 
functional areas. The R&D, engineering, construction, 
and manufacturing personnel had formed a variety of 
alliances amongst themselves, and none of these 
alliances were focused on getting the job completed on 
time to meet the business need. 

By noon on the first dav, I knew this was going to be 
an interesting challenge, to say the least. The good news 
was that the project files were organized and in good 
shape and the team members appeared competent. With 
the clock ticking, I also realized I didn’t have time to 
train new people. 1 decided to trust the remaining team 
members and focus on their strengths while trying to 
use each hour of every' day wisely to build team unitv. 

1 used the first two days to join up with each team 
member on a one-to-one basis to understand what he or 
she felt they needed to be successful. I used the informa- 
tion to define an execution strategy to meet the schedule, 
and then I began trying to break down the interpersonal 
and functional barriers I had inherited. These join-up 
meetings were a critical component for me to revise the 
existing execution strategy'. During these meetings 1 
discovered if an individual's success criteria were different 
than the team’s success criteria. Even though a person has 
agreed to the team’s criteria, they may actually be 
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motivated by other criteria, which could negatively impact 
the project. A one-to-one, face-to-face, join-up meeting 
was the only way I knew to build solid trust between the 
project manager and the team members. 

I also decided to not look back or focus on what 
caused the team to become segregated, but to focus on 
moving forward. Thus, I decided never to utter the 
words I have heard spoken often by project managers 
assuming an existing project: "You wouldn’t believe how 
screwed up this job was when 1 took over.” 
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After the first two days it was time to tackle the files 
to determine the technical scope and see yvhat omissions 
and cost issues, if any, we were facing. This strategy 
worked well and by the end of the yveek the team began 
to focus on what was needed to meet our timeline. We 
began a 24/7-work schedule yvith the project team and 
construction crew yvorking extended hours. As the davs 
passed, the team began to function better and began to 
pull together. We even made time for team-building 
activities, which yvere viewed positively and continued to 
sharpen our focus as a yvorking unit. 

To make a long story short, we performed a mirac- 
ulous turnaround, but missed the start-up date by a 
yveek. Instead of berating us for not meeting the original 
schedule, management yvas elated we came that close — 
considering yvhere yve yvere six weeks earlier. The team 
continued to yvork better and better yvith one another 
and, by the time the team disbanded twelve yveeks after 
start-up, it was a very cohesive unit. 

This experience taught me something that has been 
born out over time: A successful transition doesn’t 
necessarily lie in time spent yvith the exiting project 
manager. Don’t get me yvrong — that can be a big help. 
But the success of a transition actually lies in getting to 
knoyv the people you will be working yvith, under- 
standing their perceptions of yvhat is and isn’t working, 
and taking the time to read and analyze existing files to 
get a flavor of the project as yvell as the cost, schedule, 
and technical commitments that have been agreed to or 
modified over the course of the project. • 



W. SCOTT CAMERON is the Capital Systems 
Manager for the Food & Beverage Global 
Business Unit of Procter & Gamble. He is 
also a regular contributor to ASK Magazine. 
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PASSING THE BATON 

LESSONS IN REGRET 

By Terry Little 


I HAVE LED SIX MAJOR DEFENSE ACQUISITION PROGRAMS 

during my civil service career. For most of those, I was the 
first leader the program had and did not have to adjust to 
someone else’s legacy. This was both good and bad. 

The obvious good was that I was able, for the most 
part, to fashion things as I wanted them. These included 
patterns of interaction inside and outside the project 
office. I chose who would be in leadership positions. I 
developed the managerial philosophy and leadership 
vision. I decided my role vis-a-vis others in the office. 

I created the expectations and goals. The bad part was 
that all the while I was doing this I never considered 
what 1 might be leaving my successor to deal with. My 
reasoning was simple: I never intended to leave. I should 
have known better. 

Every time I left a program, it invariably went into a 
nosedive that lasted anywhere from a few months to, in 
one instance, more than two years. I could blame my 
successors for failing to pick up where 1 left off, but that 
would ignore the obvious. 1 was the common element in 
every case. I had failed miserably in preparing the way for 
my inevitable successor — failed five times! What had 
I done or not done? 

For one thing, I had adopted many non-standard 
practices which suited me, but would likely be unsuit- 
able for my successor. Consider earned value and 
metrics as an example. Because I did not agree with 
earned value and metrics, I simply did away with them. 
I worked on a face-to-face basis getting my information 
first hand and verbally. My way involved an amount of 
travel that any reasonable successor would simply not 
tolerate. Additionally, the DoD’s “best program manage- 
ment practices" places a lot of emphasis on using earned 
value and metrics as tools. Anyone replacing me would 
probably be adhering to these. 

The second thing I did was to make many manager- 
to-manager agreements that we never formalized in 
writing. They were just good faith understandings 
between two people. What happened when my 
successor arrived? There were no more understandings. 
My successors honored the written agreements, but had 


no allegiance to the unwritten ones I had made. 
The result was sometimes major turmoil. 

Third, I unconsciously fostered a tailored mentality 
among both the people who worked for me and the 
contractors’ project personnel. For instance, everyone 
knew that I was impatient with detail and wanted to get 
quickly to a bottom line that I could measure against my 
intuition for making decisions. Good for me, but bad for 
my successor — likely to be a more typical program 
manager who would expect detailed analysis. 

I also developed a somewhat deserved reputation as 
a bridge-burner. If one of my peers from outside the 
project office didn't agree with what 1 was doing, I simply 
went around or ignored him or her. It worked for me, but 
my successors had to rebuild lots of bridges, which took 
time, energy, and focus away from executing the project. 

I cared more for people's passion, loyalty, and their 
ability to get results than I did for how they did things. In 
that way, 1 put some real “odd-balls" in responsible 
positions. I was more than willing to sweep up any broken 
glass — a willingness that my successors did not share. 

Perhaps my worst fault was that 1 never groomed 
anyone to be my successor. I could have done that easily, 
but since I didn't intend to leave, it never occurred to me 
that I should do that. Some people take longer to learn 
from their mistakes. It has taken me failing to do this five 
times before I finally learned to begin a succession 
planning process in earnest starting from Day 1 . 

In a perfect world, a program or project would have 
one manager from birth to death. But we don't live in a 
perfect world. What should you take from all this? You 
decide. My conviction is that leading a project in a way 
that best allows a seamless transition to another leader 
at some uncertain time in the future is fundamental to 
project success. • 



TERRY LITTLE is the Director of the Kinetic 
Energy Boost Office at the Missile Defense Agency. 
One of the most seasoned program managers in DoD, 
he is also a regular contributor to ASK Magazine. 
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